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1,0  Introduction 

For  the  past  several  years  IHM,  the  Office  of  Naval  Research  (ONR),  and  the  Distributed 
Command  and  Control  (D('2)  project  at  the  Naval  Ocean  System  ('enter  (NOSC),  San  Diego 
have  co-sponsored  complementary  distributed  real-time  system  research  at  Carnegie  Mellon  Uni¬ 
versity  (CMU)  and  the  University  of  Virginia  (UVA).  ()ne  area  of  IHM  concentration  that  has 
become  of  increasing  importance  to  ONR  and  the  DC2  project  is  real-time  distributed  database 
management.  IBM,  because  of  its  involvement  in  the  design  of  real-time  submarine  combat 
systems,  had  to  address  the  real-time  issues  in  this  area  earlier  than  most  system  architecture 
researchers.  Real-time  systems  which  need  very  fast  as  well  as  predictable  respon.se  time  perform¬ 
ance  cannot  u.se  .standard  commercial  approaches  to  database  resource  and  consistency  manage¬ 
ment.  In  order  to  provide  acceptable  response  for  critical  transactions,  real-time  database 
managers  should  use  respon.se  driven  tran.saction  .scheduling,  c.g.,  ratc-monotonic  techniques. 
This  implies  that  database  managers  should  use  a  precedence  mechanism  (such  as  priority)  that  is 
based  on  transaction  response  requirements  for  selecting  which  transaction  to  process  next  and 
they  should  support  the  notion  of  preemption  so  that  transactions  with  higher  precedence  may 
move  ahead  of  already  executing  lower  precedence  transactions.  To  avoid  unbounded  precedence 
(or  priority)  inversions  resulting  from  database  consistency  management  requirements,  techniques 
such  as  the  priority  ceiling  protocol  (ref  I)  which  avoids  deadlock,  minimizes  blocking,  and  makes 
response  times  more  predictable  should  be  used.  To  provide  fast  response,  memory-based  data¬ 
base  managers  are  needed  as  well  as  special  hardware  designed  for  highly  efficient  processing  of 
relational  queries. 

IBM  has  been  very  involved  in  designing  systems  where  thc.se  characteristics  arc  essential.  IBM 
reached  the  prototyping  stage  for  real-time  relational  database  technology  in  1990,  i.c.,  the  tech¬ 
nology  became  available  for  experimenting  with  different  application  domains  such  as  command 
and  control,  .surveillance  systems,  etc.  Under  IBM  and  now  NOSC/ONR  sponsorship,  C'MU 
and  UVA  are  implementing  a  real-time  relational  database  mjinager  which  will  support  the  sched¬ 
uling  concepts  already  developed  by  C'MU  and  UVA.  CMU  and  UVA  arc  integrating  the  real¬ 
time  relational  database  manager  into  a  real-time  operating  system  in  order  to  prove  the  validity 
of  the  scheduling  theory. 

IBM  acquired  an  Ada  programmable  Versa  Module  Europa  (VME)  based  relational  processor 
(RP)  which  is  capable  of  at  least  one  order  of  magnitude  more  tran.sactions  per  second  than  is 
typical  of  currently  available  relational  databa.se  software  packages.  While  this  special  relational 
database  hardware  is  not  prccmptablc,  transactions  can  be  scheduled  by  its  control  processor. 
Because  of  its  speed  it  can  support  real-time  systems  where  use  of  a  softwarc/disk  based  relational 
database  manager  would  not  provide  acceptable  respon.se  performance.  Furthermore,  given  the 
semantic  knowledge  derived  from  a  particular  application's  implementation  it  is  possible  to  bound 
transaction  execution  times  m  that  clo.scd  form  scheduling  analysis  and  prediction  techniques  can 
be  supported. 

The  remainder  of  this  paper  describes  tlic  experiments  that  IBM  has  performed  for  NO.SC^/ONR 
in  an  initial  evaluation  of  the  relational  processor  as  applied  to  Navy  command  and  control 
trackfile  management  problems.  This  effort  uses  the  same  track  d.ita  as  NOSCFs  Distributed 
Operating  .System  lixpcriments  (DOSF.)  research  task  (ref  2). 
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l.t.l  Hardware  Configuration 

The  Real-Time  Relational  Processor  testbed  consists  of  the  I'crranli  International  Relational 
Processor  (ref  3)  and  a  DY-4  single  board  computer  (SRC)  (ref  4)  configured  on  a  VMI',  chassis. 
The  Relational  Processor  (RP)  contains  hardware  that  executes  relational  primitives  faster  than 
traditional  database  software.  I  hc  standard  8  megabyte  Relational  Processor  is  a  2  card  VMli. 
module  to  which  additional  memory  cards  can  be  added  to  bring  the  total  available  RP  memory 
to  104  megabytes.  I'he  VSR  (VMI'  sub  bus)  provides  an  interface  between  the  Relational 
Processor  and  the  6Rft20-bascd  DY-4  DVMri-137  SRC.  A  Sun  workstation  connected  to  the 
SRC  by  2  serial  ports  currently  serves  as  a  monitor,  which  passes  transaction  requests  and  data  to 
and  from  the  SRC  that  controls  the  relational  processor.  This  is  illustrated  by  l  ignre  I. 


Sun  Workstation 


Figure  I.  I larriwnrc  Configuration 

1.1.2  Software  Configuration 

riie  software  is  primarily  composed  of  Ada  control  structures  and  relational  primitive  bindings 
(SQL  is  not  used).  Perrranti  provides  the  Ada  bindings  for  the  relational  primitives  in  a  Program 
Interface  Library  (PIL).  I  hc  relational  primitives  .arc  similar  to  the  SQL  cpicry  language.  The 
Ada  application  software  is  compiled  on  a  Iclcsoft  compiler  .ami  executed  with  Ready  Systems 
ARTX  run  time  environment. 


1.1.3  DOSE  Experiment 

Rinar)'  data  enters  DOST,  in  the  Network  Interface  Unit  (NIL)  Access  Machine  .and  is  passed  to 
the  parser  manager.  Ihc  p.irscd  messages  arc  then  'Jtorcal  on  Ihc  d.il.ab.asc  of  Ihc  Track  Report 
Manager  and  displayed  by  it  c  (Iraphics  Map  Client,  t  his  is  depicted  in  T'igure  2  on  page  .V 
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Figure  2.  DOSE  Data  Flow 

The  DOSE  track  data  describes  a  set  of  contacts  over  lime  providing  track  number,  position, 
movement,  and  classification  information,  fhe  track  data  has  17  attributes  consisting  of  (loaling 
point,  characters,  and  integers. 

The  data  enters  the  system  in  blocks  of  2  to  57  tracks  which  represent  an  update  to  the  scenario. 
ITie  database  is  searched  for  each  track  number  in  the  current  block.  If  a  match  is  found,  the 
entry  for  that  track  number  is  updated  and  given  the  new  time  stamp.  If  the  track  number  is  not 
found  in  the  database,  a  new  track  is  inserted. 

In  addition  to  maintaining  history  on  the  contacts,  the  HOSE,  graphics  processor  may  request 
data  by  track  number  or  time  stamp  for  display  updates.  liither  query  will  return  ail  records 
matching  the  .selection  criteria. 


The  DOSE  database  operations  are  relatively  simple  and  arc  largely  characterized  by  the  following 
four  queries.  The  queries  u'ed  in  the  experiment  arc  given  here  in  their  original  SQT  format  and 
in  the  equivalent  RP  primitives. 

1.  INSERTION  -  Add  a  track  for  the  new  track  number. 

SQL: 

INSERT  INTO  relation  VALUES  (track,  latitude,  ...,  nuclear) 

Relational  Primitives: 

DEEINE  TUPLES  TO  ADD(buffptr.  relation,  tuple,  words) 

DEEINE  A  rT_VAL(buflfptr,  number) 

DEriNE_A  l  T  VAL(buffptr,  value) 

DEEINE  A  r'I'_VAL(bufTptr,  value) 

DEriNE_A  rr_VAL(bufTptr,  value) 

Note:  "buITptr"  indicates  the  command/input/output  buffer  being  used. 

2.  UPDATE  -  Update  previous  track  with  new  data. 


SQL: 

UPDATE  relation  SET  attribute  =  value  W 1 11  iRE  track  =  number 
repeated  for  each  attribute. 

Relational  Primitives: 

SELECTIONfbuffptr,  EQ,  tla,  track,  number) 

UPDA  TE  A  ITfbuffptr,  track,  tla,  number) 

UPDA  TE  A  l  lXbuffptr,  latitude,  tla,  value) 

UPDA  TE  A  i  rfbuffptr,  longitude,  tla,  v.aluc) 

UPDATE  Ai  rfbuffptr,  nuclear,  tla,  value) 

Note;"tla"  is  the  pointer  set  that  relates  the  SELEXyPlON  results  to  the  UPDA  rE_A'ri' 
request. 

3.  TRACK  SELECTION  •  If  found,  return  the  track  with  the  requested  track  number. 

SQL: 

SELECT  *  EROM  relation  WHERE,  track  =  number 
Relational  Primitives: 

SELECTIONfbuffptr,  E^Q,  tla,  track,  number) 

OUTPUT(bulTptr,  tla,  0,  0) 

4.  TIME  SELECTION  -  If  found,  return  all  tracks  with  the  requested  time. 

SQL: 

SELECT  *  E'ROM  relation  WHERE’ time  “  gmt 
Relational  Primitives: 

SEI  E,C  riONfbuffplr,  I'Q,  tla,  time,  gmt) 

OUTPU  Tfbulfptr,  tla,  0,  0) 


1,2  Time  Measurement  Methodology 

I'o  measure  the  required  processing  time  for  a  RP  transaction,  a  10  ms  system  clock  was  avail¬ 
able.  Because  individual  database  transactions  execute  on  the  RP  in  much  less  time  th:m  a  single 
10  ms  clock  tick,  it  was  ncccss.'iry'  to  pciform  multiple  itcr.aticms  of  the  same  Irans.action  to  get  an 
accurate  measurement  of  the  processing  time.  .As  the  number  of  iterations  increased  to  approxi¬ 
mately  100,  the  actual  processing  time  became  apparent.  Eigure  .1  on  page  5  illustrates  this 
point. 
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F'lgurc  3.  Update  Attribute  (1000  liiplcs) 

Transaction  processing  time  includes  RP  processing  time,  tlie  time  associated  witli  transferring  the 
command  and  input  buffers  across  the  VSB,  as  well  as  the  overhead  involved  in  the  Ada  con¬ 
structs  needed  to  duplicate  the  (low  of  control  of  the  DOSP,  scenario.  By  synchronizing  a  timer 
with  the  signals  .sent  across  the  VSB,  it  would  be  possible  to  eliminate  all  processing  not  occurring 
on  the  RP,  but  the  method  chosen  provides  a  better  cstim.ite  of  the  amount  of  time  required  for 
real-world  applications. 

The  RP  can  be  programmed  to  amortize  transaction  overhead  processing  over  a  few  or  many 
commands.  Consequently,  performance  was  measured  for  both  approaches  as  described  below. 


1.2.1  Multiple  Commands  -  Sequence  A 

In  order  to  minimize  communication  over  the  VSB,  the  RP  .allows  multiple  commands  to  be 
placed  in  sequence  in  the  command  buffer.  Certain  operations  may  not  appear  more  than  once  in 
these  command  buffers,  but  the  basic  functions  required  by  our  experiments  arc  not  of  this 
nature.  By  grouping  a  number  of  commands  and  transmitting  the  buffer,  all  ovcrhc.ad  except  for  a 
single  VSB  trans,action  was  avoided,  and  the  limes  resulting  from  this  method  arc  much  lower 
than  Sequence  B  where  command  blocking  was  not  performed. 


1.2.2  Multiple  Iterations  -  Sequence  B 

riic  second  method  was  to  execute  single  transactions  inside  a  loop,  and  divide  the  elapsed  time 
by  the  number  of  iterations  before  converting  to  seconds.  I  bis  method  includes  the  amount  of 
time  necessary  for  loop  control  processing,  but  by  placing  clock  queries  within  the  loop  ;uul 
adding  up  the  individual  elapsed  times,  this  overhead  was  found  to  be  negligible.  However,  over¬ 
head  associated  with  command  and  data  transfers  prove*!  to  be  very  significant. 


L3  Insert  Measurements 


An  insert  was  performed  on  a  database  witli  75  records  (the  approximate  si/c  of  the  DOSIl  data¬ 
base)  and  on  a  database  of  1000  records.  By  increasing  (lie  numl?cr  of  iterations  on  the  database 
with  75  records,  the  time  required  stabilized  to  0.4  ms  for  .Sequence  A  and  1.5  ms  for  .Sequence  B 
as  illu.strated  in  Figure  4.  Increa.sing  the  .size  of  the  datab.asc  to  1000  records  has  little  impact  on 
the  response  time  as  illustrated  in  I'igure  5  on  page  7. 


time  (ms) 


Figure  4.  Insertion  (75  tuples) 
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time  (ms) 


Figure  5.  Insertion  (1000  tuples) 

1,4  Update  Measurements 

Update  measurements  were  performed  for  updating  an  entire  tuple  whicli  consists  of  17  attributes 
as  well  as  for  a  single  attribute  in  the  tuple. 

Tuple  update  performance  measurements  were  made  on  databases  with  7,5  records  and  a  1000 
records.  In  the  database  with  75  records,  the  resulting  time  stabilizes  to  1.6  ms  for  Sequence  A 
and  2.2  ms  for  .Sequence  1).  Increasing  the  si/.e  of  the  table  to  1000  records  bad  an  insignificant 
impact  on  the  required  processing  time. 

Next,  tuple  update  was  performed  for  various  database  sizes  with  a  constant  number  of  iterations. 
Ihe  RF  is  relatively  insensitive  to  the  number  of  tuples  in  the  database  as  shown  in  I'igurc  6  on 
page  R. 
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Figure  6,  Update  Tuple  (50  ifciations) 

An  attribute  update  was  performed  varying  the  number  of  iterations  while  maintaining  tlic  si7c  of 
the  database.  Tor  a  database  of  75  tuples,  the  resulting  time  stabilizes  to  0.2  ms  for  .Secpicnce  A 
and  1.3  ms  for  Sequence  B.  The  same  results  arc  seen  for  a  database  with  1000  tuples. 

Also  an  attribute  update  was  performed  for  various  database  sizes.  Again,  increasing  the  number 
of  tuples  had  very  little  impact  on  the  time  required  to  perform  the  update  as  shown  in  Pigure  7 
on  page  9. 
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Figure  7.  Update  Attribute  (250  iterations) 

1,5  Selection  Measurements 

Track  and  time  selections  were  measured  in  several  ways. 

A  sclectUm  resulting  in  one  matching  tuple  was  measured  over  numerous  iterations  while  main¬ 
taining  the  size  of  the  database.  For  a  Time"  selection,  it  was  found  that  the  Sequence  A  time 
was  0.1  ms  and  for  Sequence  I)  the  time  was  .1.7  ms.  I'hc  "track"  selection  performs  the  select 
using  the  primary  key  and  the  resulting  response  time  was  the  same  as  the  above  "time"  selection. 

Next,  several  selections  were  performed  varying  the  number  of  matching  tuples  while  maintaining 
the  size  of  the  databa.se  and  the  number  o(  iterations.  These  res'dts  are  shown  in  Figure  S  on 
page  10. 
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Figure  8.  Selection  (Sequence  A,  75  tuples) 

I'inally,  a  selection  was  performed  var>'ing  the  size  of  llie  database  while  maintaining  a  constant 
number  of  iterations.  Again  the  Rf’  response  time  rcrnaiticd  flat  as  the  si/c  of  the  database 
increased.  Fagurc  9  on  page  1 1  depicts  these  mca.surcmcnts. 
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Figure  9.  Selection  (750  iterntions) 

L6  Summary 

Our  experiments  with  the  Relational  Processor  liavc  shown  it  to  be  a  viable  technology  for  use  in 
Navy  command  and  control  systems.  In  particular,  the  DOSF-  scenario  requires  that  approxi¬ 
mately  45  tracks  per  second  be  processed.  Based  on  the  experiments  with  1-erranti  s  Relational 
Processor  it  should  be  able  to  handle  a  sustained  rate  of  590  to  2375  tracks  per  second  depending 
on  the  ratio  of  updates  to  inserts  as  determined  by  the  existing  database.  I  bis  performance  is 
more  than  an  order  of  magnitude  greater  than  required;  however,  these  numbers  would  have  to  be 
derated  by  the  amount  of  query  activity  directed  at  the  Rcl.ational  Processor,  for  instance,  by  the 
DOSIv  graphics  proccs.sor.  Sec  lugure  10  on  page  12  to  obtain  performance  estimates  for  various 
mixes  of  track  updates  to  inserts.  While  time  did  not  permit  measurements  varying  the  number  of 
attributes  in  a  tuple,  information  obtained  from  the  manufacturer  indicates  that  the  Relational 
Processor's  performance  appears  to  be  more  sensitive  to  the  number  of  attributes  than  the 
number  of  tuples.  All  measurements  in  this  experiment  were  m.'ule  with  the  17  HOSI'.  attributes. 
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Figure  10.  Mix  of  Inserts  anil  Updates  lia.scd  on  Selection 

The  experiments  involved  database  sizes  ranging  from  75  to  1000  tuples.  I'hc  Relational  Process¬ 
or's  response  characteristics  proved  to  be  flat  over  this  range.  The  maximum  size  of  (he  database 
which  can  be  processed  by  the  Relational  I’roccssor  is  rcsfriclcd  by  the  size  of  its  volatile  memory'. 
The  Relational  Processor  exiicriments  used  S  megabytes  but  can  be  expanded  to  104  megabytes. 

Additional  areas  deserv'ing  future  evaluation  include  time  driven  scheduling  of  the  RI’,  perform¬ 
ance  sensitivity  to  databases  larger  than  1000  tuples  and  performance  sensitivity  to  the  number  of 
attributes  in  a  relation.  l  urthermore,  it  would  be  advantageous  to  cxcrci.se  the  Relational 
Processor  in  a  distributed  system  network,  permitting  the  mca.surcmcnt  of  additional  forms  of 
system  overhead  that  cou'd  further  degrade  the  deliverable  performance  of  the  Relational 
Processor  in  a  real-world  application. 

This  tcchni’logy  has  great  promise  for  future  command  and  control  as  well  as  other  applications 
where  speed  and  insensitivity  to  database  size  are  important  characteristics.  rhe  inability  to 
preempt  the  relational  processor  once  it  has  started  processing  a  command  buffer  has  an  impact 
on  system  transaction  schedulability.  However,  given  its  performance,  insensitivity  to  dat.ibasc 
extent,  and  semantic  information  about  its  use  in  p.ulicular  applications,  this  weakness  could 
often  be  overcome  by  judicious  application  programming  such  that  Imunded  rcspon.se  lime  gu.ar- 
antecs  could  be  supported. 
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